Medium access control protocol for data communications

ABSTRACT

A method for controlling communication between a hub and a plurality of distributed stations over a medium is disclosed. The method comprising the steps of a method for controlling communications access between a hub ( 8 ) and a plurality of distributed stations (M 1 -M 7 ) over a medium, the method comprising the steps of (a) allocating a plurality of channels for data communications between the station (M 1 -M 7 ) and the hub ( 8 ), the number of channels being at least equal to the number of stations, (M 1 -M 7 ) and each station owning at cast one channel, each channel being varyingly in one of an empty-, a reserved, or an owner-state, and whereby (i) the empty-state provides a channel to which any station (M 1 -M 7 ) can have access; (ii) the reserved-state provides a channel to which a station (M 1 -M 7 ) having made a reservation with the hub ( 8 ), but not owning the channel, can have access; and (iii) the owner-state provides a channel to which only the owning station (M 1 -M 7 ) has access; and (b) allocating the respective state and/or the number of channels over time an the basis of each station&#39;s data requirements.

FIELD OF THE INVENTION

This invention relates to the field of data communications, and tomethods and apparatus to implement a Medium Access Control (MAC)protocol therefor. The invention has particular (but not exclusive)application in wireless communications environments such as μ-wave,mm-wave or infra-red. The term “data communications” is to be understoodin its broadest sense to include data per se, and forms such as voiceand video.

BACKGROUND OF THE INVENTION

For discussion purposes, reference will be made to wireless MACprotocols, however it should be understood that the invention is equallyapplicable to cabled (ie. wire and optical fibre) and wireless datacommunications alike.

A protocol generally is a set of agreed conventions (methodology) forhandling the exchange of information between communication processing“elements”.

In a wireless medium, the capacity to accommodate multiple users seekingaccess to the medium must take into account fundamental limitations ofbandwidth. For any wireless data communications system there is a finitedata carrying capacity, and this capacity must be shared between userson an appropriate basis to satisfy the user's requirements. A number ofMAC protocols have been devised for this purpose. Such protocolsvariously attempt to satisfy the objective of providing users withaccess to the full medium during times of low load demand, and fairaccess to the medium during times of high load demand. Furthermore, itmay be desirable to guarantee a user the ability to transmit or receivea burst of data on demand regardless of other user load demands.

Usually, users requesting access to a wireless medium will require lowreception delays and high throughput. Where wireless data communicationservices are supplied on a subscription basis, the subscribing usersnegotiate certain guaranteed performance requirements that have to bemet in order for the service provider to retain that subscriber'sloyalty.

Known protocols fall broadly within four classes: fixed access, randomaccess, guaranteed access, and hybrid protocols.

The fixed access category includes those MAC protocols where eachstation is allocated a fixed proportion of the available bandwidth. Thiscategory includes time division multiple access (TDMA), frequencydivision multiple access (FDMA) and code division multiple access (CDMA)protocols. The main problem with fixed access protocols is that they arenot flexible enough to efficiently meet the dynamic bandwidthrequirements of a local area network (LAN) environment. Additionally,such a protocol could not be operated as the sole access method, as thebandwidth allocation must be established Initially, and reestablishedwhen mobile stations move between wireless areas.

A random access protocol is only statistical in its nature and thereforeits performance is never guaranteed. There are many examples of randomaccess protocols including those based on ALOHA, Carrier Sense MultipleAccess (CSMA) and collision resolution. Random access protocols cangenerally be characterised by the following properties. At low aggregateloads a random access protocol usually provides low delay. At highloads, contention will limit throughput and increase delay. Schedulingof transmission by a random access protocol also is difficult due to thelack of guarantees about access to the wireless medium. Similarly,prioritised access to the wireless medium cannot be ensured. ALOHAprotocols also tend to ignore collisions, whereas CSMA protocols tend totry and avoid collisions or limit the length of collisions.

Guaranteed Access Protocols, as the name suggests, guarantee access tothe medium, and may be achieved using either distributed or centralisedcontrol mechanisms. Examples of guaranteed access protocols includepolling protocols, token passing protocols and some collision resolutionprotocols.

Most practical, implementable wireless MAC protocols are designed as ahybrid of two or more protocols from the previously describedcategories. This allows a wireless MAC protocol to be tailored moreeasily to provide a range of services given a particular set of wirelessphysical layer properties. Hybrid protocols are mostly based on the ideaof contention on the wireless medium followed by a reservation thatholds the wireless medium for a single station without contention.

R-ALOHA is a hybrid protocol that includes elements of random accessprotocols and guaranteed access protocols. R-ALOHA is based on slottedALOHA with regular allocation of slots. If a station is successful intransferring a data unit in a slot then it may reserve the same slot insubsequent frames. Reserved access to future slots reduces contention,thus increasing throughput and reducing delay. R-ALOHA has twounsatisfactory aspects. Firstly, it only allows a station to reserve oneslot per frame which is too inflexible in a LAN environment. Secondly, astation may keep a slot reserved without restriction, which may resultin unfairness and long delays.

A variation of R-ALOHA, Packet Reservation Multiple Access (PRMA),solves these problems for voice traffic. PRMA supports periodic dataunits (voice traffic) and random data units (data traffic). Onlyperiodic data units can reserve the same slot in future frames. Randomdata units always use slotted ALOHA access. Problems similar to thoseexperienced for R-ALOHA are avoided in two ways. Firstly, periodic dataunits are buffered only for a limited period before they are transmittedor discarded, thus reducing the load during congestion. Secondly,stations must give up reservations between, talk spurts. PRMA is thusvery dependent on the properties of speech for effective operation.Another example of this physical layer dependence is that the frame ratein PRMA is tied to the speech rate.

In a published paper entitled “A Dynamic packet-switching system forSatellite Broadcast Channels”, (ICC'75, San Francisco, June 1975) theauthor Binder describes a TDMA based satellite communication schemewhere all stations own a channel (or channels) in a frame structure. Theframe may have more channels than those owned by stations. All stationsreceive each transmitted packet via the satellite. Each packet headerincludes a reservation for the station's queued packets. Stations whichdo not have a current reservation will have their owned channel used forreservation access. Each station allocates reservation requests on around-robin basis. A station with new packets to transmit may regain itsowned channel by causing a collision. In the next frame all stationswill consider the channel reserved by its owner which can then make areservation request. A master station generates frame markers andtransmits the reservation state. This is used by new stations andstations which have lost a packet and hence the reservation sequence.

There is a problem here, however, with packets received with errors. Ifthe packet contained reservations which were processed by otherstations, then the receiving station cannot use the reservation schemefor the rest of the frame. This is hard to distinguish from intentionalcollisions intended to free an owned channel. In addition, a stationmust receive what it transmits to detect a purposeful collision.

The Motorola ALTAIR™ system uses a reservation protocol with timemultiplexed request and data channels in a slotted frame. The start ofthe frame contains request slots in which user modules (UM) makerequests to a central control module (CM) using slotted ALOHA accesswith an adaptive transmission probability. The end of the frame containsa series of grant slots, which specify the allocation of data slots inthe next frame, and a series of management slots. The middle part of theframe contains data slots from the CM to the UMs and allocated dataslots from the UMs to the CM. Control information is distributed throughblocks at the start and end of a frame with intervening data slots. Themobile station needs to track where it is in this structure and it willlose considerable efficiency if it has a problem receiving a criticalblock.

An access request is made by competitive ALOHA in the start controlblock with no feedback until the end of frame control block. Accessslots occur in the midst of a potentially long series of user slots. Anyfailure to track the user slot sequence will affect a station'sthroughput and the throughput of any other station it collides with.Bandwidth must be consumed to provide guard time between these slots toallow for variation in clock speed between stations.

A more generic reservation protocol than ALTAIR™ was proposed byInternational Business Machines Corp. for use as the basis of the IEEE802.11 Standard. It uses a slotted frame with three sections (A, B andC). Each section is preceded by a variable length header containingmanagement information related to the section, including its length.Section A contains the data units from the hub station to the wirelessstations, section B contains data units in reserved slots from thewireless stations to the hub station or other wireless stations andsection C contains slots used by the wireless stations to sendreservations or short data units using a random access protocol.Requests may be for either asynchronous or isochronous bandwidth.

The IBM protocol (disclosed in U.S. Pat. No. 5,384,777, Ahmadi et al,entitled “Adaptive Medium Access Control Scheme for Wireless LAN”)recognises the importance of power conservation by specifying that allnecessary control information is carried in the header at the start ofeach section. The header indicates when data units will be sent to awireless station in section A and when the wireless station has slotsallocated in section B. The wireless station may power-down at othertimes and during section C if it does not need to send any data units.However, this functionality requires real time interpretation of complexvariable length headers, making the IBM protocol an unlikely candidatefor high speed operation. Problems in common with the ALTAIR™ systemalso equally apply.

Recently, the IEEE 802.11 Working Group selected a MAC protocol,Distributed Foundation Wireless MAC (DFWMAC), that will form the basisof all future work. DFWMAC is a very complex protocol with a number ofoptional facilities that are supposed to allow it to operate with arange of physical layer properties. It also has nodes of operation thatallow it to operate with and without the coordination provided by a hubstation.

DFWMAC's fundamental mode of operation is known as a distributedcoordination function. It uses a CSMA/CA protocol where a mobile stationensures that the channel is clear for a minimum period beforetransmission. Priority is implemented by ensuring that the sensingoccurs for a minimum period depending on the priority level of the dataunit. Thus, DFWMAC assumes that the physical layer supports carriersensing. To avoid the ‘hidden terminal problem’, a mobile station mayoptionally also use an RTS/CTS type protocol similar to MA/CA to ensurethat long data units do not collide with each other. To ensure errorfree operation, data units are immediately acknowledged at highpriority. A disadvantage of carrier sensing is the significant timespent listening to determine that the wireless medium is free. Then theradio unit must be switched from receive to transmit, which takesfurther significant time.

DFWMAC also includes a second mode of operation, known as a pointcoordination function, which effectively provides a synchronous dataunit service. In this mode, a central hub station divides the bandwidthinto a frame consisting of a contention free period and a contentionperiod. During the contention free period, a hub station polls mobilestations on a poling list. The hub station starts a contention freeperiod by sending the first poll at a high priority. The reservationmechanism is entirely unsophisticated: ‘send a message during thecontention period’. There are no methods to respond to bursty traffic orto attempt to make efficient use of the medium.

U.S. Pat. No. 4,970,720, Hiroshi Esaki assigned to Toshiba K K, entitled“A Packet Communication Exchanging Apparatus” describes an even simplerCSMA/CA scheme for wired and wireless LANs. Here a station causes acollision to obtain access to the medium by forcing active stations todelay access attempts.

DISCLOSURE OF THE INVENTION

The present invention is directed to overcoming or at least amelioratingone or more of the disadvantages in the prior art. Embodiments describedherein specify a medium access control protocol that provides mechanismsto make efficient use of the available wireless transmission capacitywhile supporting the operation of synchronous and asynchronouscommunications, with guaranteed performance according to negotiatedparameters, between a mobile station and a hub station.

Therefore, the invention broadly discloses a method for controllingcommunications access between a hub and a plurality of distributedstations over a medium, the method comprising the steps of:

(a) allocating a plurality of channels for data communications betweenthe stations and the hub, the number of channels being at least equal tothe number of stations, and each station owning at least one channel,each channel being varyingly in one of an empty-, a reserved-, or anowner-state, and whereby:

(i) the empty-state provides a channel to which any station can haveaccess;

(ii) the reserved-state provides a channel to which a station havingmade a reservation with the hub, but not owning the channel, can haveaccess; and

(iii) the owner-state provides a channel to which only the owningstation has access: and

(b) re-allocating the respective state and/or the number of channelsover time on the basis of each station's data requirements.

The invention further discloses a method for controlling communicationsaccess between a hub and a plurality of mobile stations via a pluralityof channels providing data access therebetween, there being at least asmany channels as mobile stations, and the channels being varyingly inone of an empty-, a reserved-, or an owner-state, and whereby:

(i) the empty-state provides a channel to which any station can haveaccess;

(ii) the reserved-state provides a channel to which a station havingmade a reservation with the hub, but not owning the channel, can haveaccess; and

(iii) the owner-state provides a channel to which only the owningstation has access;

the method comprising the steps of re-allocating the respective stateand/or the number of channels over time on the basis of each station'sdata requirements.

The invention yet further discloses a communications system havingcontrolled data access to a medium, the system comprising:

a hub having transceiving means for communication via the medium anddata processing means;

a plurality of distributed stations, each having transceiving means forcommunication with the hub via the medium and data processing means;

and wherein said data processing means of the hub and the stationsco-operate to allocate a plurality of channels for data communicationsbetween the stations and the hub, the number of channels being at leastequal to the number of stations, and each station owning at least onechannel, each channel being varyingly in one of an empty-, a reserved-,or an owner-state, and wherein:

(i) the empty-state provides a channel to which any station can haveaccess,

(ii) the reserved-state provides a channel to which a station havingmade a reservation with the hub, but not owning the channel, can haveaccess, and

(iii) the owner-state provides a channel to which only the owningstation has access, and co-operate to re-allocate the respective stateand/or the number of channels over time on the basis of each station'sdata requirements.

The invention yet further discloses a hub for a communications system,operable to have controlled data access to a medium in co-operation witha plurality of distributed stations, the hub comprising:

transceiving means for communications via the medium; and

data processing means coupled to the transceiving means;

and wherein said data processing means of the hub is operable toallocate a plurality of channels for data traffic between the stationsand the hub, the number of channels being at least equal to the numberof stations, each channel being varyingly in one of an empty-, areserved-, or an owner-state, and wherein:

(i) the empty-state provides a, channel to which any station can haveaccess,

(ii) the reserved-state provides a channel to which a station havingmade a reservation with the hub, but not owning the channel, can haveaccess, and

(iii) the owner-state provides a channel to which only the owningstation has access, and further operable to re-allocate the respectivestate and/or the number of channels over time on the basis of eachstation's data requirements.

The invention yet further discloses a wireless local area network havinga medium access protocol to control access, the network comprising:

a hub having transceiving means for communication via free space pathsand data processing means;

a plurality of distributed stations, each having transceiving means forcommunication with the hub via free space paths and data processingmeans;

and wherein said data processing means of the hub and the stationsco-operate to allocate a plurality of channels for data traffic betweenthe stations and the hub, the number of channels being at least equal tothe number of stations, and each station owning at least one channel,each channel being varyingly in one of an empty-, a reserved, or anowner-state, and wherein:

(i) the empty-state provides a channel to which any station can haveaccess,

(ii) the reserved-state provides a channel to which a station havingmade a reservation with the hub, but not owning the channel, can haveaccess, and

(iii) the owner-state provides a channel to which only the owningstation has access, and co-operate to re-allocate the respective stateand/or the number of channels over time on the basis of each station'sdata requirements.

Embodiments of the invention have the benefit of simultaneously: (a)guaranteeing a minimum access to the network transmission capacity foreach mobile station according to negotiated channel parameters, (b)unreserved capacity can be used by other mobile stations, therebyproviding such mobile stations with capacity in excess of a guaranteedminimum, and obtained independent of hub control and without requiringadditional complexity in the mobile unit, and (c) provides parameters tomaximise the probability of successful transmission by one mobilestation in situations of competitive access to a slot, includingregistration slots and empty slots.

One characteristic of the medium access protocol is that it is demandoriented rather than a requesting type known in the prior art.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention now will be described with reference to theaccompanying drawings, in which:

FIG. 1 is a schematic block diagram of a wireless system upon which aMAC protocol embodying the invention can be implemented;

FIG. 2 is a schematic block diagram of a wireless LAN system in anotherembodiment;

FIG. 3 is a schematic block diagram of a wired network system in afurther embodiment;

FIG. 4 is a schematic block diagram of a hub station;

FIG. 5 is a schematic block diagram of a mobile/radio station;

FIGS. 6 to 9 show the structures of transmission in a wireless cell;

FIG. 10 is a state diagram for timing and scheduling of a hub station;

FIGS. 11 a-11 c show state diagrams for a mobile station; and

FIGS. 12 to 15 show graphs of throughput and delay for simulatedcontention situations.

DESCRIPTION OF PREFERRED EMBODIMENTS AND BEST MODES NetworkConfiguration and Elements

FIG. 1 shows a simplified form of a wireless system 5, in which a singletransceiving hub station 8 facilitates data communications between anumber of distributed transceiving mobile stations 9. The mobilestations 9 can be mobile within a cell (not shown) controlled by the hubstation 8. The hub station 8 acts to coordinate bidirectional datacommunications between the mobile stations 9, in the example shown,between stations M1 and M3.

FIG. 2 shows a wireless LAN system 10. Four hub stations (H1-H4) 8 areinterconnected via a backbone network, in this case star cabled links 11connected to a switching unit 6. The star network 11 and switching unit6 equally can be replaced by another backbone network with differenttopology, including a ring network, and with different media includingwireless. Each hub station 8 has an associated wireless cell 13 withinwhich are located various mobile stations (M1-M7). A computing device 14also has connection to the network II, as does a gateway 15 providingaccess to a generic ISDN network 16. Data communications can be betweenones of the mobile stations 9, between a mobile station 9 and thecomputing device 14, or between a mobile station 9 and another devicelocated on the ISDN network 16. Again, the hub stations 8 act tocoordinate the flow of data to and from the mobile stations.

FIG. 3 shows a block diagram of a wired network system 17, upon which aprotocol embodying the invention also can be implemented. As previouslynoted, the invention is not limited to wireless environments. A numberof terminals (T1-T5) 9′ are in cabled connection 13′ with a hub station(H1). The cabled connection 13′ has the characteristic that the hubstation H1 communicates with the terminals 9′ using broadcasttransmissions. The hub station, in turn, can be in cabled connectionwith a computer 14 and a like hub station (H2) (not shown). The hubstation H1 coordinates data communications between the terminals T1-T5and the computer 14. The arrangement of FIG. 3 is simplified inasmuch asthere could be many hub stations and associated terminals,interconnected by a backbone wired or wireless network that providesduplex communication between the hub stations 8′.

In a broad form, it can be considered that a hub station 8 or 8′operates on one set of rules to control access to the medium by a numberof stations 9 or 9′, or either to each other, or to compatible unitsaccessible via a network 11 attached to the hub station 8 or 8′. Thestations 9 or 9′ use a different set of rules to respond to the hubstation based on their internal states.

As shown in FIG. 4, a number of component blocks for a hub station 8 areprovided. These take the form of a network interface 20, a buffer memory21, a framing, forward error correction (FEC) and modulating section 22,a framing, forward error correction and demodulation section 23, an IF(intermediate frequency) system section 24, a radio receiver 25, a radiotransmitter 26, and an antenna 27 which is sufficiently broad in itsradiation pattern to illuminate the entire cell 13. The antenna 27 canachieve this result statically or dynamically (with electronic ormechanical beam steering). All these items are connected to, and areoperable by, a control and timing section 28. In addition, all arepowered by an AC mains or battery operable power supply 29.

Equivalent portions of the mobile station 9 are indicated by adesignator having a magnitude higher by 10 in FIG. 5. The mobile station9 has a battery-powered power supply 39.

Further details concerning a modulation and demodulation implementation,as a form of ensemble modulation, are disclosed in commonly owned U.S.Pat. No. 5,487,069 (equivalent to Australian Patent No. 666411 andEP-A-0 599 632) entitled “A Wireless LAN”, the contents of which areincorporated herein by cross-reference.

It will be noted that the antenna 37 is preferably a steerable antennawhich is electronically steerable by the control and timing section 38to at least partially direct the transmissions to and from the mobilestations 9 towards the corresponding hub station 8. A suitable antennafor this purpose is that disclosed in commonly owned Australian PatentNo. 671214 (equivalent to EP-A-0 632 523 and U.S. Pat. No. 5,714,961)entitled “A Steerable Antenna”, the contents of which also are herebyincorporated by cross-reference.

Software implementing a MAC protocol embodying the invention resides inthe timing and control elements 28,38 of a hub station 8 and mobilestation 9 respectively.

A characteristic of the communications medium which is important in thefollowing descriptions is referred to as “capture”. This may occur insome embodiments under certain conditions. When multiple mobile stationstransmit in the same slot the hub station may receive either:

-   (a) a garbled data unit which cannot be interpreted; this is called    “collision” and no “capture” has occurred, or-   (b) a correct data unit where the mobile with the strongest signal    has swamped the others; this is “capture”.

Data Link Procedures

The description of the data link procedures will proceed with referenceto the system shown in either FIGS. 1 or 2, and particularly wirelesscommunications between a hub station 8 and a mobile station 9.

FIG. 6 shows that access to the cell transmission capacity is dividedinto slots S that alternate between the up-link (mobile to hub) and thedown-link (hub to mobile). Each slot carries a data unit M together withphysical layer overheads, as shown in FIG. 7.

Slots are organised into channels. A channel is the set of eitherdown-link (hub to mobile) or up-link (mobile to hub) slots, respectivelyaddressed, to or owned by the same mobile station. Each up-link channel,if allocated to a mobile station, is said to be owned by it.

A hub station uses the down-link both to transfer data units to mobilesand to facilitate medium access control operations in the cell. A hubstation transmits data units in one of two classes: (i) managementtraffic, including invitation to register, and (ii) data traffic.

When there are no mobile stations registered, the hub station data unitsrelate principally to registration. Unregistered mobile stations use amodified ALOHA protocol to deliver registration requests to the hubstation. These requests include the station's unique MAC address, calledthe station-id. This is included in the registration confirmationresponse from the hub station to avoid ‘capture’ related problems.

When a mobile station registers it obtains the channel identifier of its“owned” channel from the hub station. The hub station allocates afraction of the available data transfer time to the new mobile andenters it in a scheduling database. The hub station also allocates dataunit storage resources for the mobile.

The hub station transmits data units to a specific mobile by setting thestation-id of the mobile in the header of the data unit.

The hub station uses a scheduling algorithm to determine which channelwill be allocated for a down-link and for the following up-link. Mobilesuse a modified R-ALOHA protocol, along with their internal state, todetermine use of the up-link.

Each down-link data unit contains an acknowledgment in its header thatthe hub station sets if it received a data unit correctly in the lastup-link slot. This acknowledgment includes the sending station-id toavoid the problem of the capture effect. Mobile stations use theacknowledgment to determine if the data unit they just transmitted wassuccessfully received by the hub station.

A mobile can negotiate for hub station support to achieve batteryconservation. In this case, time-critical prompts will be exclusivelydirected to this mobile which include controls to allow it to ignore,management and data traffic for a period.

Following registration, a mobile station can request that the hubstation adjust the parameters controlling its traffic servicecharacteristics.

A wireless medium is subject to unpredictable variations and occasionalloss of transmissions. To reduce the impact of any such loss the controlelements of the MAC protocol are distributed in time. Instead of channelaccess information forming a block part of a frame header, it isdistributed through the headers of each slot transmitted by the hubstation.

The protocol data units (PDU) arc constituted differently for theup-link and down-link. FIG. 8 shows the protocol data unit fields forthe down-link, while FIG. 9 shows the protocol data unit fields for theup-link. Tables 1A & 1B describe these fields.

TABLE 1A Hub station protocol data unit fields Field Description dest-idIdentifier of the destination for the payload source-id Identifer of thesource of the payload. type An identifier for a down link data unitformat, additionally distinguishing between data and managementpayloads. chan-id Channel identifier for the following up-link. This isin the range 0 to (max_number_allocated_channels − 1) orregistration_chan_id (a known number outside that range) chan-state Thestate of the following up-link slot: empty, owner or reserved (Note: theregistration channel is always in empty-state) up-link_result The resultof last up-link transmission as ack or nack. ack-id If up-link_result =ack, ack-id is the identifier of the successful source mobile stationelse unused. est-num For the next up-link slot: For registration:estimated number of registering mobile stations For data: estimatednumber of active mobile stations sleep-num The duration of sleepfollowing next up-link slot. payload For a data transmission: fixedlength data, eg 4 × 53 bytes. For a management transmission: managementdata units including beacon, management request and management response.crc Data unit integrity check.

TABLE 1B Mobile station protocol data unit fields Field Descriptiondest-id Identifier of the destination for the payload source-idIdentifier of the source of the payload. type An identifier for an uplink data unit format, additionally distinguishing between data andmanagement payloads. flow-rq Flow request for this channel contend-rqRequest to be counted as a mobile station competing for ALOHA slots.payload For a data channel: fixed length data, eg 4 × 53 bytes For amanagement transmission: management data units including registrationrequest, management request and management response. crc Data unitintegrity check.

Hub Station Operation

Operation of the hub station 8 in the wireless cell now will bedescribed with reference to FIG. 10, which is a state machine relatingto the timing of the alternating hub-originated and mobile-originatedtransmission sequence. The process state 40 includes the handling of anyreceived data units from the mobile stations, the processing ofacknowledgments, and the generation of the next down link data unit. Thetransition from the process state 40 to the transmit state 41 iscontrolled by a slot tick 43 generated by a clock (not shown). Uponcompletion of a slot transmission, the hub moves to the receive state42. The hub returns to the process state 40 upon reception of a dataunit from a mobile station or after a specified time period.

The transfer of data units out of the wireless cell, ie. to and from abackbone network, may be accomplished asynchronously from the handlingof data units to and from the mobiles, and is governed by the protocolon the backbone network.

Hub Cycle

The hub station includes the channel identifier of the next up-link slotin the header part of each down-link slot. Although a channel may beused by any mobile station, priority is given to the mobile station thatowns the channel. The sequencing of channels is determined by the‘schedular’ process in the hub station taking into account therequirements of each mobile station, including the required serviceparameters and sleep requirements. Every mobile station registered in acell is allocated at least one channel. In this way, all mobile stationscan be guaranteed some access to the network.

Consecutive up-link and down-link slot pairs are scheduled over a frame.A frame structure is maintained by the hub station and describes thechannel sequence for the down-link and the up-link. However, the notionof a frame has no significance outside the hub station, and mobilestations do not need to hold state information about frames. The hubstation cycles through the frame structure selecting down-link andup-link channels according to the frame entries.

The information needed to dimension a frame is delivered to the hubstation in management requests from the mobiles. The number of slotpairs in a frame is decided dynamically by the hub station, taking intoaccount the number of mobile stations registered in the wireless celland the type and channel parameters they require. The maximum framelength may be determined by the minimum allowable channel data ratesupported by the network. The frame size may change to accommodatemobile station service requirements or changes in the number of mobilestations.

Hub Station Initialisation

The hub station scheduler is initially set for no registered mobiles. Inthis state, all down-link and up-link slots may be allocated to themanagement channel, with the intention that they be used forregistration.

Hub Registration Process

The registration channel is selected from time to time by the Scheduler.Mobiles use a modified form of slotted-ALOHA to deliver a registrationrequest to the hub station. Failures and successes are used by the hubstation to generate an estimate of the number of mobiles attempting toregister (see Table 2 below). If the registration succeeds the hubstation records the channel identifier for the mobile and informs theScheduler.

TABLE 2 Hub station registration estimation process Change toRegistration up-link result estimated # of Next down-link Mobile TxCollision registrants ack/nack no no 0 (see Note) nack yes yes +2 nackyes no −1 ack Note: The absence of any activity for a pre-defined longperiod of time should result in the estimate being set to zero.

The hub station must provide some specific information to the newlyregistered mobile station. This includes the channel identifier for thefirst channel to be owned by the mobile station, and other networkparameters which will be delivered by management packets.

Hub Channel Operation

The hub station always transmits in down-link slots to mobile stationsin a cell. The down-link payload may contain data originating fromwithin the cell, from elsewhere in the network, or from the hub stationitself. Fields in the headers of each down-link slot allocate a channelto the next up-link slot and constrain mobile access to that channel.

Each up-link channel is defined to be in one of three states (empty,reserved or owner). The hub station stores the state of each channel andtransmits the state of the next channel (along with other controlfields) to the mobile stations in the header field of each down-linkslot. The three channel states are defined as follows:

Empty-state

If a data channel is in the empty-state, any mobile station with queueddata units is allowed to contend for access to it using a slotted ALOHAprotocol. Mobile stations may make reservations for the channel infuture frames according to a modified R-ALOHA protocol.

Reserved-state

If a channel is in the reserved-state, the mobile station that hasreserved the channel may transmit a data unit. However, the owner of thechannel may sometimes use it regardless of the mobile station that hasreserved the channel.

Owner-state

If a channel is in the owner-state, only the mobile station that ownsthe channel may use it to transmit a data unit. Channels allocated to amobile station with negotiated channel parameters are called“provisioned” and remain in the owner-state. Thus the owner of a channelhas guaranteed access.

At the end of each up-link slot the hub station changes the channelstate according to the State Table shown in Table 3, and selects thenext channel according to a scheduling algorithm.

TABLE 3 Up-link data channel state transitions Up-link State⁴ Up-linkResult⁴ Next Send Provisioned Channel Mobile is Mobile Flow UpdateChannel ack/ Channel State Owner Tx Collision Request est-num State nackno empty or X yes yes X no owner nack reserved¹ no empty or no yes nores yes reserved ack reserved² no empty or yes yes no own yes owner ackreserved² no empty or X yes no no yes empty ack reserved³ no empty or Xno no no no empty nack reserved³ no owner yes yes no own yes owner ackno ″ X yes no no yes empty ack no ″ X no X X no empty nack yes ″ yes yesno X yes owner ack yes ″ yes yes yes X no owner nack yes ″ yes no no Xno owner nack Where X = don't care. Note: ¹Owner pre-emption.²Reservation. ³End of flow. ⁴Other states represent protocol errorstates which may be due to hub station failure, mobile failure or adenial of service attack. The appropriate response may include a hubstation restart.

The columns under “Provisioned Channels”, “Up-link State” and “Up-linkResult” describe the type of the channel, the state of the channel andthe result of the latest reception on that channel. The “Update est-num”column indicates whether to use the up-link contend-rq field to updatethe estimated number of contending mobiles (ic. est-num). In the righthand columns the new state for the channel is given and the “Sendack/nack” column shows what should be sent in the next down-link slot inresponse to the mobile's data unit.

The hub station is required to acknowledge and to count mobile stationswhenever their contend-rq signal indicates that they will be contendingfor ALOHA slots. The hub station transmits a mobile'station estimate ina field in the MAC header part of every down-link.

If a mobile station is to be counted by the hub station then it makes acontend-request in the header part of an up-link slot at the same timeit attempts to send a data unit.

The hub must exchange management data units with mobile stations forcontrol tasks which may include registration completion (which mightinvolve security), channel parameter negotiation and sleep control. Thechannel parameter negotiation may alternatively be delivered by standardsignaling procedures.

Hub Station Scheduler

The hub station may enter into contracts with mobile stations to providecertain channel parameters in which it will allocate a portion of theavailable capacity for the use of that mobile station. The protocoldescribed herein supports guaranteed channel parameter contracts. Thehub station supports these contracts with a scheduler that is fair anddoes not degrade the performance of any existing contracts. Theacceptance of a contract requires the allocation of hub stationresources up to, but not exceeding, the hub station's total (bandwidth)capacity.

Hub Sleep Scheduling

The protocol described herein supports a mode of operation in which themobile enters a low-power mode that does not require it to listen toevery down-link slot. For a mobile indicating a sleep requirement, theslot scheduler can allocate owned slots during the period when themobile is awake.

Mobile Station Operation

A mobile station's operation will be described with reference to FIG.11.

Mobile cycle

The activity of the mobile station is determined in response to messagesreceived from the hub station. FIG. 11 a shows that a mobile stationoperates in three states ‘init’ 50, ‘registration’ 51, and ‘data’ 52.The state ‘registration’ 51, entered after initialisation or as a resultof losing contact with the hub, is expanded in FIG. 11 b. Anunregistered mobile station is in the ‘registration-listen’ state 53 inwhich it waits for the hub to issue a registration slot. The mobileenters the ‘request-registration’ state 54 if it attempts to register.The ‘data’ state 52 is expanded in FIG. 11 c. A mobile receivesdown-link slots from the hub in ‘data-receive’ state. 55. Down-link dataunits are processed in state ‘data-process’ 56. Depending on the outcomeof the processing, the mobile either exits the ‘data’ state 52 or entersone of three states: the ‘data-transmit’ state 57 in which it transmitsa data unit in the next up-link slot; the ‘data-sleep’ state 58 in whichit conserves power; or the ‘data-receive’ state 55.

Mobile Registration

In the ‘registration’ state 51 shown in FIG. 11 a, the mobile operatesin accordance with the Registration State Table shown in Table 4 below.The objective of the procedures described by the Registration StateTable is to competitively deliver a message to the hub station. The hubstation provides an estimate of the number of mobiles it believes areattempting to register. A mobile uses the inverse of this number to setthe probability of transmitting its registration request. This is usedto increase the probability of a successful registration transmission bydelaying, or spreading in time, registration requests of the contendingmobile stations.

TABLE 4 Mobile registration state table Result Next Mobile Tx Mobile Hubre- Mobile Channel identifier Probability Tx sponse Stateregistration_chan_id 1/(est-num + 1) yes nack registra- tionregistration_chan_id 1/(est-num + 1) yes ack data registration_chan_id1/(est-num + 1) no X registra- tion other 0 no X registra- tion

In Table 4, ‘Channel identifier’ is the ‘chan-id’ field in the previousdown-link protocol data unit. ‘Mobile Tx probability’ is used by themobile station to set the probability that it will attempt to access thechannel. The next two columns describe the result of the mobile accessattempt: ‘Mobile Tx’ states whether or not the mobile did attempt toaccess the channel, and ‘Hub response’ is the response by the hubstation that appears in the down-link slot immediately following theregistration attempt and defines whether the registration attempt hassucceeded.

Mobile Channel Parameter Request

The mobile station requests channel characteristics consistent with thehub station's scheduling algorithm. The method of delivery of thisrequest to the hub station depends on the networking environment, butcan be accomplished though management processing.

Mobile Data Transmission

The following section further describes the operations carried out inthe ‘data’ state 52 of FIG. 11 a and its expanded form in FIG. 11 c.

The header in an up-link data unit may include a flow request (see Table1B) that is set by a Mobile station to reserve exclusive access to thechannel. The logic to allow reservations to be made is given in theState Table of Table 5 below. A successful reservation results in achannel being temporarily re-allocated to the mobile station that madethe request. This allows the transmission of data in the channel (calleda “flow”) until the reservation is relinquished by the mobile stationdropping the flow request, or the channel is reclaimed by the owner. Twotypes of “flow” are recorded: owner-flow and reserve-flow.

TABLE 5 Mobile data state table Flow Record Update Current StateTransmission Transmission Result mobile Decision ACK & ACK & has FlowRelease increment ack-id = ack-id ≠ channel flow in queue RequestPre-empt Re- Tx request Flow station- station- state channel ownerlength Allowed Allowed quired Probability flow Counter id id NACK no Txunknown X X X X X X 0 no^(d) empty X no >0 no X X 1/(est_num + 1) no nono no no no ″ X no >0 yes X X 1/(est_num + 1) res no res no no no ″ Xyes >0 no no X 1/(est_num + 1) no no no no own no ″ X yes >0 no yes X 1no no no no own ″ X yes >0 yes yes X 1 own no own no own reserved noyes >0 no yes X 1 no no no no own ″ no yes >0 yes yes X 1 own no own noown ″ yes no >0 no X X 1 no yes no no no ″ yes no >0 yes X no 1 res yesres no no ″ yes no >0 yes X yes 1 no yes no no no owner X yes >0 no X X1 no no no no own ″ X yes >0 yes X X 1 own no own no own all other casesno where ^(d)= in addition a down link slot error should be counted, X =don't care

In Table 5, the ‘Current state’ columns give the state following receiptof a down-link data unit. The ‘Transmission decision’ columns indicatewhether the mobile station should transmit, what flow requests should bemade and consequent action. The ‘Tx Probability’ specifies theprobability that the mobile station will transmit. In three cases thetransmission probability is determined from the hub station's estimateof the number of mobiles contending for ALOHA access. To compress thetable, the Flow Record Update′ columns are separated according towhether a transmission was made (first 3 columns) or not (4th column).The first 3 columns specify how the mobile station should update itsflow record for each of three possible acknowledgment responses in thenext down-link data unit. The action here modifies the flow status ofthe channel just used. Entry ‘no’ means that there is no owner orreserve flow and ‘res’ or ‘own’ means that ‘reserve flow’ or ‘ownerflow’ respectively is recorded.

Table 5 also specifies that the mobile station should count errored dataunits, indicated in the table by ‘channel state’=‘unknown’. This numbercan be used to decide when the link has become unreliable and remedialaction needs to be taken, ie. a return from ‘data’ state 52 to the‘registration’ state 51 shown in FIG. 11 a.

Also, whenever a mobile transmits it sets its contend-rq field accordingto Table 6 to assist the hub station in its determination of the numberof mobiles contending for empty slots.

TABLE 6 Mobile station Contend-Rq Generation Queue length Contend-Rq >1yes ≦1 noOwner Flow Requests

An owner-flow request is a flow request made by a mobile station for achannel that it owns. On receipt of an owner flow request the hubstation changes the channel state to owner, meaning only the owner ofthe channel is allowed access to the channel. This facility allows theowner of a channel to dynamically create a contention free TDMA-likechannel for its own use. Even if the hub station does not receive theslot containing the owner-flow request correctly, due to a collision orother error, the request is still successful because the hub stationassumes that the owner of the channel has caused the collision to regainaccess to the channel. This state will not persist unnecessarily as theowner must request retention of owner-state in successive slots.

An owner-flow request must receive a positive acknowledgment with theowner ack-id to be considered successful. A mobile station that makes anowner-flow request marks the channel as an owner flow and increments“Flows”, a counter in each mobile station that represents the totalnumber of flows that the mobile station currently holds. Similarly, theend of a flow must result in “Flows” being decremented.

A mobile station will make an owner-flow request for a channel only ifthe data in its queue cannot be transmitted in the flows that the mobilestation has already been granted.

Reserve Flow Requests:

A reserve-flow request is a flow request made by a, mobile station forany channel that it does not own. If the slot containing a reserve-flowrequest is correctly received by the hub station, it changes the channelstate to reserved-state.

If the slot containing the reserve-flow request is not correctlyreceived by the hub station it is assumed that the owner of the channelhas caused a collision in order to regain access to the channel. The hubstation changes the channel state to owner-state, which is the sameaction as for incorrectly received slots containing an owner-flowrequest.

A mobile station making a reserve-flow request must wait for an explicitacknowledgment, with the ack-id matching the station-id (to avoid the“capture” problem) that the request was received correctly by the hubstation before marking the channel as a reserve-flow and incrementing“Flows”. The acknowledgment to the reverse-flow request is controlled inthe header of the next down-link slot.

A mobile station should make a reserve-flow request for a channel onlyif the data in its queue cannot be transmitted in the flows that themobile station has already been granted. Specifically, there must bepotential to transmit all data using just one access to each of thegranted flows.

After a mobile station receives a down-link data unit it must use itscurrent state, shown in the Current State columns of Table 5 and Table6, to decide whether and how it is going to transmit a data unit in thenext up-link slot. The mobile station's Current State consists of:

“Channel State”—the state of the channel determined by the hub station.

“Mobile has flow in chan”—indicates if a reserve-flow or owner-flow isrecorded for the channel.

“Owner”—indicates that the Mobile station owns the channel.

“Queue Length”—the number of data unit payloads in the Mobile station'squeue.

FlowRequestAllowed=(QueueLength>Flows+1).

Pre-emptAllowed=(Queue Length>Flows).

ReleaseRequired=(FlowCounter=0).

Given a particular current state, the appropriate action is shown in thetransmission decision columns in Table 5. If the “Tx Probability” isone, the mobile station always transmits. If the “Tx Probability” iszero, then the mobile station must not transmit a data unit. If a dataunit is transmitted then the “request reserve-flow” and “requestowner-flow” columns indicate whether a “reserve-flow request” or an“owner-flow request” respectively should be made.

A parameter, “FlowMax” is defined and a counter “FlowCounter” isrequired in each mobile station. Every time a mobile station transmits adata unit in a reserve-flow, the mobile station increments “FlowCounter”modulus “FlowMax”. The value of “FlowMax” is a configurable parameter.If “FlowCounter” equals zero when a mobile station is about to transmita data unit in a reserved-flow, the mobile station must not requestcontinuation of the reserved-flow irrespective of the state of its queueor the number of other flows it currently holds. A mobile station neverhas to release an owner-flow because they are not considered to be partof the sharing process.

In general terms, low values for FlowMax are always unsatisfactory asthey limit throughput, while large values give good throughput but poordelay. A broad range of intermediate values can provide goodperformance.

The “increment FlowCounter” column of Table 5 indicates whether“FlowCounter” should be incremented modulus “FlowMax”.

The transmission result block in Table 5 shows the action that is takenafter reception of the next down-link slot that may contain anacknowledgment of any data unit transmitted.

Mobile Sleeping

A battery powered mobile station may wish to remove power from someparts of its electronic circuitry whenever its operation is notrequired, and thus can enter the ‘data-sleep’ state 58 shown in FIG. 11c. This is supported by the Hub station's scheduling process.

Performance Data

Negotiated access by stations can be scheduled without contention andwith delays agreed upon. The remaining traffic involves contended accessto the network, including traffic subject to statistical multiplexing.This contended traffic has been the subject of simulation.

Two independent methods were used to perform the simulation. The resultshown here were derived from a software implementation of the protocolusing the C programming language. In this simulation the hub and mobilestations, were each implemented as a thread, where all communicationsamong them were restricted to information in the packet exchangesillustrated in FIGS. 11. The traffic used in the simulations wasgenerated using Poission statistics. The base simulation unit was atime-slot, instead of absolute time in seconds, as a result theperformance illustrated is valid for arbitrary slot sizes.

These simulation results were verified using a commercial simulationpackage called OPNET, supplied by MIL 3, Inc, 3400 International Drive,Washington D.C. 20008.

FIGS. 12-15 variously have as an indices ‘Offered Load’ vs ‘Throughput’,where a value of 1 indicates the whole part of the bandwidth availablefor non-guaranteed traffic and ‘Delay’ vs ‘Throughput’. The channel mayhave scheduling, agreements for, say, 90% of its capacity, with theremaining 10% being subject to contention.

FIGS. 12 and 13 show the situation of ten mobile stations competing withequal probability for network access. The hub does round-robinscheduling of the ten slots owned by the stations.

The throughput plot shows that the protocol is converting the OfferedLoad directly to throughput over almost the entire range. Also shown onFIG. 12 is additional protocol-related traffic required to obtaincompetitive access. This region between “data” and “data+ collision”shows increasing activity as the probability of slotted ALOHA typecollisions increases as load increases, then a progressive reduction asthe protocol's behaviour becomes more TDMA like. The delay remainsbetter than that achieved in pure TDMA, conventionally taken to be1+(no. slots /2), in this case 6 slots, until the offered load reaches0.3. Then it increases as collisions cause delayed access. However thisstill stays quite low until the offered load approaches 0.9. At thispoint mean delay grows rapidly because a TDMA mode of operation is notuniformly established and where collision is still being used to obtainaccess queue length (hence delay) will increase.

FIGS. 14 and 15 relate to a simulation where there are again tenstations being offered their owner slots on a round-robin basis.

However, one station (causing “heavy” traffic) is generating 90% of thesystem's Offered Load while the other nine stations (causing “light”traffic) evenly share the remaining 10% of the Offered Load. Note thatthere are no traffic agreements here. The Offered Loads are still forthe contended pan of the system bandwidth only.

The system Throughput directly matches the Offered Load up to an OfferedLoad of around near 0.8. The “heavy” traffic station will attempt to useall the slots it requires while “light” traffic stations willincreasingly need to collide to temporarily reserve their owned slots todeliver a packet. The region representing collisions shows thisbehaviour. As the system load becomes high, the “light” station willneed to use nearer and nearer to 10% of the channel. To obtain this theywill consume an increasing part of the bandwidth in collisions. So,after reaching a peak, throughput will decline as collisions become morelikely. As the decision to transmit is probabilistic, even the(data+collision Throughput) cannot reach 1.

At the same time, the “heavy” station will have increasing difficultyemptying its queue and its delay increases sharply. On the other hand,the “light” stations can regain their owned channel and dispatch theirpackets before another arrives. FIGS. 13 and 15 show very good Delayperformance.

This demonstrates excellent fairness, in that the heavy user did notprevent stations with modest requirements from using the network.

Embodiments of the invention provide advantages (or avoid disadvantages)over the prior art MAC hybrid protocols discussed earlier. In relationto R-ALOHA the present MAC protocol attempts to reserve multiple slotsdepending on how many data units have been buffered. However, it doesnot retain reserved slots beyond its immediate need to use them orbeyond the specified consecutive number of accesses. Also, in comparisonwith R-ALOHA there is an improvement in performance by stations owningchannels which can be preempted on demand, where the demand includescollision of transmission, and also by structuring up-link and down-linkslots so as to provide immediate feedback to a previous transmissionattempt. In relation to the PRMA protocol, the present protocol, incontrast, does not distinguish between “voice” and “other” traffic, inwhich case there is no reliance on characteristics of voice traffic,such as freedom to discard data units, or relatively fixed frame rates.The technique of obtaining access to reserved slots has been enhanced bythe concept of “owner channel” which may be rapidly forced into areserved-state rather than waiting for an ALOHA access to succeed.

Turning now to the ALTAIR™ system, for the present protocol controlinformation is distributed in time and each slot access is controlled bythe previous slot header and acknowledged by the following slot header.Failure to read one of the control messages will result in the loss ofonly one slot access, which is a small impact. Further, the presentprotocol uses a number of schemes to generate access, including theguaranteed reservation, thereby obviating the need for complex feedback.Finally, the present protocol allows mobile stations to respond directlyto hub station messages, in that there is no requirement to determinewhen a granted slot number occurs. There also is no requirement foraccurate timing by the mobile stations. Rather, only the hub station'stiming is important to avoid unwanted unused time.

Turning now to the IBM protocol, the same observations over and above inrelation to ALTAIR™ apply, together with the added advantage that thepresent protocol is less complex as there is a less involved overallstructure and powering down is directed by the hub station.

Turning finally to the DFWMAC protocol, in comnparison, the presentprotocol has the ability to respond to bursty traffic and to makeefficient use of the available medium. Furthermore, the protocol is ableto specify when a mobile station may sleep because of the definedcentralised control, which otherwise is more difficult to achieve in adistributed control system.

While the wireless LAN and wired network embodiments have beendescribed, the invention has numerous other applications, including thefollowing.

The MAC protocol can be used to control the resources in a wireless LANwhere a number of computers, some of which may be mobile, are connectedto each other and/or a wired backbone LAN. The MAC protocol could alsobe used to control access to a wireless access point for an ATM network,commonly referred to as wireless ATM. This could be for the access ofmobile of fixed computer terminals to an ATM network or for connectingtogether physically separated ATM networks.

Another area of application is the delivery of entertainment services,Internet and telephony services to the home or office. This could beusing coaxial cable systems, hybrid fibre coaxial cable systems, hybridfiber-radio systems or fiber to the kerb followed by radio or Copperwire-based access to the home or office. In these applications, the MACprotocol is used to control access to and from a home/office, butparticularly on the so-called back channel (transmission from thehome/office to the head-end) where a number of users share the samebandwidth for data and/or telephony.

The MAC protocol can have further applications in radio based personalcommunications systems where both voice and data traffic is generated bymobile handsets or terminals.

The MAC protocol can have further applications in point to multi-pointradio communications systems where a number of stations arecommunicating to a central station which may be connected to acommunications network. Such systems may be used in wireless back-handfor mobile communications networks such as trunked radio or GroupSpeciale Mobile (GSM).

A yet further application is for wireless systems in homes or officesfor the distribution of entertainment services and data between aset-top box provided by a service provider to a number of televisions,and/or computers and associated peripherals. it is possible to extendthe MAC protocol to include the establishment of peer to peer networks.These are networks where there is no controlling hub station, but acollection of mobile terminals which wish to communicate amongstthemselves. These extension enable communications to occur.Alternatively, it may be possible to have a mobile terminal(s) withhardware and software to enable it to operate as a hub station usingthis MAC protocol.

1. A method for controlling communications access between a hub and aplurality of distributed stations over a medium, the method comprisingthe steps of: (a) the hub allocating a plurality of channels, for datacommunications between the stations and the hub, the number of channelsbeing at least equal to the number of stations, and each station owningat least one channel, and wherein each channel is varyingly in adistinct one of an empty-, a reserved-, or an owner-state, and wherein:(i) the empty-state provides a channel to which any station can haveaccess; (ii) the reserved-state provides a channel having an owner andto which a station having made a reservation with the hub, but notowning the channel, can have access if not being used by the owner, andfurther to which the owner can resume access on demand; and (iii) theowner-state provides a channel to which only the owning station hasaccess; and (b) the hub re-allocating the respective state and/or thenumber of channels over time on the basis of each station's datarequirements.
 2. A method as claimed in claim 1, wherein the datacommunication is over a medium having finite bandwidth.
 3. A method asclaimed in claim 1, wherein there are at least as many channels in theowner-state as there are stations.
 4. A method as claimed in claim 1,comprising the further step of a station at any time requesting of thehub to be allocated one or more extra channels.
 5. A method as claimedin claim 1, whereby a channel further provides for management trafficbetween each station and the hub, and comprises the further step, asmanagement traffic, of a station negotiating with the hub to beallocated a required number of channels in the owner-state.
 6. A methodas claimed in claim 5, comprising the further step of a stationnegotiating with the hub to be allocated a required number of channelsin the reserved-state.
 7. A method as claimed in claim 5, comprising thefurther steps of a station requesting an indication of the number ofstations seeking to register, and the hub responding thereto, whereinsaid station receives said indication by request and indication.
 8. Amethod as claimed in claim 5, comprising the further steps of a stationrequesting an indication of the number of stations seeking to register,and the hub responding thereto, wherein said station receives saidindication by broadcast.
 9. A method as claimed in claim 5, comprisingthe further steps of a station requesting an indication of the number ofstations seeking to use a channel and the hub responding thereto,whereby said station receives said indication by request and indication.10. A method as claimed in claim 5, comprising the further steps of astation requesting an indication of the number of stations seeking touse a channel and the hub responding thereto, whereby said stationreceives said indication by broadcast.
 11. A method as claimed in claim5, comprising the further step of a station requesting the hub to bederegistered to give-up allocated channels.
 12. A method as claimed inclaim 5, comprising the further step of a station requesting the hub todelay any data communication to the station for a period of time to bein a sleep mode.
 13. A method as claimed in claim 1, wherein the step ofre-allocation includes temporarily ascribing use of reserved-statechannel to a non-owning station.
 14. A method as claimed in claim 13,whereby said temporary use is rescinded following lapse of a time periodof no use by the ascribed station.
 15. A method as claimed in claim 1,wherein each said channel has a plurality of uplink and downlink slots,and comprising the further step of the number of slots within a channelbeing variable to account for each station's data requirements.
 16. Amethod for controlling communications access between a hub and aplurality of mobile stations via a plurality of channels providing dataaccess therebetween, there being at least as many channels as mobilestations, and the channels is varyingly in a distinct one of an empty-,a reserved-, or an owner-state, and wherein: (i) the empty-stateprovides a channel to which any station can have access; (ii) thereserved-state provides a channel having an owner and to which a stationhaving made a reservation with the hub, but not owning the channel, canhave access if not being used by the owner, and further to which theowner can resume access on demand; and (iii) the owner-state provides achannel to which only the owning station has access; the methodcomprising the steps of the hub re-allocating the respective stateand/or the number of channels over time on the basis of each station'sdata requirements.
 17. A method as claimed in claim 16, wherein the datacommunication is over a medium having finite bandwidth.
 18. A method asclaimed in claim 16, whereby a channel further provides for managementtraffic between each station and the hub, and comprises the furtherstep, as management traffic, of a station negotiating with the hub to beallocated a required number of channels in the owner-state.
 19. A methodas claimed in claim 16, wherein the medium is free space.
 20. A methodas claimed in claim 16, comprising the further step of a stationnegotiating with the hub to be allocated a required number of channelsin the reserved state.
 21. A method as claimed in claim 16, comprisingthe further steps of a station requesting an indication of the number ofstations seeking to register, and the hub responding thereto, whereinsaid station receives said indication by request and indication.
 22. Amethod as claimed in claim 16, comprising the further steps of a stationrequesting an indication of the number of stations seeking to register,and the hub responding thereto, wherein said station receives saidindication by broadcast.
 23. A method as claimed in claim. 16,comprising the further steps of a station requesting an indication ofthe number of stations seeking to use a channel, and the hub respondingthereto, wherein said station receives said indication by request andindication.
 24. A method as claimed in claim 16, comprising the furthersteps of a station requesting an indication of the number of stationsseeking to use a channel, and the hub responding thereto, wherein saidstation receives said indication by broadcast.
 25. A method as claimedin claim 16, comprising the further step of a station requesting the hubto be deregistered to give-up allocated channels.
 26. A method asclaimed in claim 16, comprising the further step of a station requestingthe hub to delay any data communications to the station for a period oftime to be in a step mode.
 27. A method as claimed in claim 16, wherebythe step of reallocation includes the step of temporarily ascribing useof reserved-state channel to a non-owning station.
 28. A method asclaimed in claim 27, whereby said temporary use is rescinded followinglapse of a time period of no use by the ascribed station.
 29. A methodas claimed in claim 16, wherein each said channel has a plurality ofuplink and downlink slots, and comprising the further step of the thehub varying the number of slots within a channel to account for eachstation's data requirements.
 30. A communications system havingcontrolled data access to a medium, the system comprising: a hub havingtransceiving means for communication via the medium and data processingmeans; a plurality of distributed stations, each having transceivingmeans for communication with the hub via the medium and data processingmeans; and wherein said data processing means of the hub allocates aplurality of channels for data communications between the stations andthe hub, the number of channels being at least equal to the number ofstations, and each station owning at least one channel, and wherein eachchannel is varyingly in a distinct one of an empty-, a reserved-, or anowner-state, and wherein: (i) the empty-state provides a channel towhich any station can have access, (ii) the reserved-state provides achannel having an owner and to which a station having made a reservationwith the hub, but not owning the channel, can have access if not beingused by the owner, and further to which the owner can resume access ondemand, and (iii) the owner-state provides a channel to which only theowning station has access, and co-operate to re-allocate the respectivestate and/or the number of channels over time on the basis of eachstation's data requirements.
 31. A system as claimed in claim 30,wherein the stations are mobile and the medium is free space.
 32. Asystem as claimed in claim 30, wherein the data communications is over amedium having finite bandwidth.
 33. A system as claimed in claim 30,wherein there are at least as many channels in the owner-state as thereare stations.
 34. A system as claimed in claim 30, wherein a stationdata processing means, at any time, requests from the hub dataprocessing means to be allocated one or more extra channels.
 35. Asystem as claimed in claim 30, wherein the hub data processing meansfurther provides for management traffic between each station and thehub, and the management traffic includes a station negotiating with thehub to be allocated a required number of channels in the owner-state.36. A system as claimed in claim 35, wherein a station data processingmeans negotiates with the hub data processing means to be allocated arequired number of channels in the reserved-state.
 37. A system asclaimed in claim 35, wherein a station data processing means requests anindication of the number of stations seeking to register, and the hubdata processing means responds thereto, and wherein said stationreceives said indication by request and indication.
 38. A system asclaimed in claim 35, wherein a station data processing means requests anindication of the number of stations seeking to register, and the hubdata processing means responds thereto, and wherein said stationreceives said indication by broadcast.
 39. A system as claimed in claim35, wherein a station data processing means requests an indication ofthe number of stations seeking to use a channel and the hub respondingthereto, and wherein said station receives said indication by requestand indication.
 40. A system as claimed in claim 35, wherein a stationdata processing means requests an indication of the number of stationsseeking to use a channel and the hub responding thereto, and whereinsaid station receives said indication by broadcast.
 41. A system asclaimed in claim 35, wherein a station data processing means requeststhe hub data processing means to be deregistered to give-up allocatedchannels.
 42. A system as claimed in claim 35, wherein a station dataprocessing means requests the hub data processing means to delay anydata communication to the station for a period of time to be in a sleepmode.
 43. A system as claimed in claim 30, wherein re-allocationincludes temporarily ascribing use of reserved-state channel to anon-owning station.
 44. A system as claimed in claim 43, wherein saidtemporary use is rescinded following lapse of a time period of no use bythe ascribed station.
 45. A system as claimed in claim 30, wherein eachsaid channel has a plurality of uplink and downlink slots, and whereinthe hub varies the number of slots within a channel to account for eachstation's data requirements.
 46. A hub for a communications system,operable to have controlled data access to a medium in co-operation witha plurality of distributed, stations, the hub comprising: transceivingmeans for communications via the medium; and data processing meanscoupled to the transceiving means; and wherein said data processingmeans of the hub is operable to allocate a plurality of channels fordata traffic between the stations and the hub, the number of channelsbeing at least equal to the number of stations, and wherein each channelis varyingly in a distinct one of an empty-, a reserved-, or anowner-state, and wherein: (i) the empty-state provides a channel towhich any station can have access, (ii) the reserved-state provides achannel having an owner and to which a station having made a reservationwith the hub, but not owning the channel, can have access if not beingused by the owner, and further to which the owner can resume access ondemand, and (iii) the owner-state provides a channel to which only theowning station has access, and further operable to re-allocate therespective state and/or the number of channels over time on the basis ofeach station's data requirements.
 47. A hub as claimed in claim 46,wherein the stations are mobile and the medium is free space.
 48. A hubas claimed in claim 46, wherein the data communications is over a mediumhaving finite bandwidth.
 49. A hub as claimed in claim 46, wherein thereare at least as many channels in the owner state as there are stations.50. A hub as claimed in claim 46, wherein a station data processingmeans, at any time, requires from the hub data processing means to beallocated one or more extra channels.
 51. A hub as claimed in claim 46,wherein the hub data processing means further provides for managementtraffic between each station and the hub, and the management trafficincludes a station negotiating with the hub to be allocated a requirednumber of channels in the owner-state.
 52. A hub as claimed in claim 51,wherein a station data processing means requests an indication of thenumber of stations seeking to register, and the hub data processingmeans responds thereto, and wherein said station receives saidindication by request and indication.
 53. A hub as claimed in claim 51,wherein a station data processing means requests an indication of thenumber of stations seeking to register, and the hub data processingmeans responds thereto and wherein said station receives said indicationby broadcast.
 54. A hub as claimed in claim 51, wherein a station dataprocessing means requests an indication of the number of stationsseeking to use a channel, and the hub responding thereto, and whereinsaid station receives said indication by request and indication.
 55. Ahub as claimed in claim 51, wherein a station data processing meansrequests an indication of the number of stations seeking to use achannel, and the hub responding thereto, and wherein said stationreceives said indication by broadcast.
 56. A hub as claimed in claim 51,wherein a station data processing means requests the hub data processingmeans to be deregistered to give up allocated channels.
 57. A hub asclaimed in claim 51, wherein a station data processing means requiresthe hub data processing means to delay any data communication to thestation for a period of time to be in a sleep mode.
 58. A hub as claimedin claim 46, wherein a station processing means negotiates with the hubdata processing means to be allocated a required number of channels inthe reserved-state.
 59. A hub as claimed in claim 46, whereinre-allocation includes a temporarily ascribing use of reserved-statechannel to a non-owning station.
 60. A hub as claimed in claim 59,wherein said temporary use is rescinded following lapse of a time periodof no use by the ascribed station.
 61. A hub as claimed in claim 46,wherein each said channel has a plurality of uplink and downlink slots,and wherein said data processing means varies the number of slots withina channel to account for each station's data requirements.
 62. Awireless local area network having a medium access protocol to controlaccess, the network comprising: a hub having transceiving means forcommunication via free space paths and data processing means; aplurality of distributed stations, each having transceiving means forcommunication with the hub via free space paths and data processingmeans; and wherein said data processing means of the hub allocates aplurality of channels for data traffic between the stations and the hub,the number of channels being at least equal to the number of stations,and each station owning at least one channel, and wherein each channelis varyingly in a distinct one of an empty-, a reserved-, or anowner-state, and wherein: (i) the empty-state provides a- channel towhich any station can have access, (ii) the reserved-state provides achannel having an owner and to which a station having made a reservationwith the hub, but not owning the channel, can have access if not beingused by the owner, and further to which the owner can resume access ondemand, and (iii) the owner-state provides a channel to which only theowning station has access, and the hub re-allocates the respective stateand/or the number of channels over time on the basis of each station'sdata requirements.
 63. A wireless local area network as claimed in claim62, wherein the stations are mobile and the medium is free space.
 64. Awireless local area network as claimed in claim 62, wherein the datacommunications is over a medium having finite bandwidth.
 65. A wirelesslocal area network as claimed in claim 62, wherein there are at least asmany channels in the owner state as there are stations.
 66. A wirelesslocal area network as claimed in claim 62, wherein a station dataprocessing means, at any time, requires from the hub data processingmeans to be allocated one or more extra channels.
 67. A wireless localarea network as claimed in claim 62, wherein the hub data processingmeans further provides for management traffic between each station andthe hub, and the management traffic includes a station negotiating withthe hub to be allocated a required number of channels in theowner-state.
 68. A wireless local area network as claimed in claim 67,wherein a station data processing means requests an indication of thenumber of stations seeking to register, and the hub data processingmeans responds thereto, and wherein said station receives saidindication by request and indication.
 69. A wireless local area networkas claimed in claim 67, wherein a station data processing means requestsan indication of the number of stations seeking to register, and the hubdata processing means responds thereto, and wherein said stationreceives said indication by broadcast.
 70. A wireless local area networkas claimed in claim 67, wherein a station data processing means requestsan indication of the number of stations seeking to use a channel, andthe hub responding thereto, and wherein said station receives saidindication by request and indication.
 71. A wireless local area networkas claimed in claim 67, wherein a station data processing means requestsan indication of the number of stations seeking to use a channel, andthe hub responding thereto, and wherein said station receives saidindication by broadcast.
 72. A wireless local area network as claimed inclaim 67, wherein a station data processing means requests the hub dataprocessing means to be deregistered to give up allocated channels.
 73. Awireless local area network as claimed in claim 67, wherein a stationdata processing means requires the hub data processing means to delayany data communication to the station for a period of time to be in asleep mode.
 74. A wireless local area network as claimed in claim 67,wherein re-allocation includes a temporarily ascribing use ofreserved-state channel to a non-owning station.
 75. A wireless localarea network as claimed in claim 74, wherein said temporary use isrescinded following laps of a time period of no use by the ascribedstation.
 76. A wireless local area network as claimed in claim 62,wherein a station processing means negotiates with the hub dataprocessing means to be allocated a required number of channels in thereserved-state.
 77. A wireless local area network as claimed in claim62, wherein each said channel has a plurality of uplink and downlinkslots, and wherein the hub varies the number of slots within a channelto account for each station's data requirements.
 78. A method forcommunications access between a hub and a plurality of distributedstations over a medium, comprising providing a plurality of channels fordata communications between the stations and the hub, wherein eachchannel is varyingly in a distinct one of an empty-, a reserved-, or anowner-state, and wherein: (i) the empty-state provides a channel towhich any station can have access; (ii) the reserved-state provides achannel having an owner and to which a station having made a reservationwith the hub, but not owning the channel, can have access if not beingused by the owner, and further to which the owner can resume access ondemand; and (iii) the owner-state provides a channel to which only theowning station has access.
 79. The method of claim 78, wherein thenumber of channels is variable but at least equal to the number ofstations.
 80. A method for controlling communications access between ahub and a plurality of distributed stations over a medium supporting aplurality of channels for data communications between the stations andthe hub, the number of channels being at least equal to the number ofstations, and each station owning at least one channel, comprising: thehub dynamically allocating the number of channels and the respectivestate, and wherein each channel is varyingly in a distinct one of anempty-, a reserved-, or an owner-state, and wherein: (i) the empty-stateprovides a channel to which any station can have access; (ii) thereserved-state provides a channel having an owner and to which a stationhaving made a reservation with the hub, but not owning the channel, canhave access if not being used by the owner, and further to which theowner can resume access on demand; and (iii) the owner-state provides achannel to which only the owning station has access.
 81. A hub for acommunications system, operable to have controlled data access to amedium in co-operation with a plurality of distributed stations, the hubcomprising: transceiving means for communications via the medium; anddata processing means coupled to the transceiving means, and operable todynamically allocate a plurality of channels for data traffic betweenthe stations and the hub, the number of channels being at least equal tothe number of stations, and each channel being varyingly in a distinctone of an empty-, a reserved-, or an owner-state, and wherein: (i) theempty-state provides a channel to which any station can have access,(ii) the reserved-state provides a channel having an owner and to whicha station having made a reservation with the hub, but not owning thechannel, can have access if not being used by the owner, and further towhich the owner can resume access on demand, and (iii) the owner-stateprovides a channel to which only the owning station has access.